home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Network CD 1
/
Network CD.iso
/
tbag
/
1-10
/
tb7
/
doc-files
/
cli.docs
< prev
next >
Wrap
Text File
|
1986-09-11
|
14KB
|
307 lines
=======================================================================
CLI.docs
=======================================================================
************************ ConMan v0.95 **************************
ConMan is a replacement console handler that provides line editing and
command line histories. It runs under AmigaDOS (V1.1 or V1.2) and is
completely transparent to any application program that uses CON: windows.
Programs that use RAW: input are unaffected.
Once installed, any windows opened by AmigaDOS will automatically open
using the ConMan handler. This includes command windows opened by
NEWCLI as well as any data input/output windows that your program uses.
New features have been added to v095B, including support for the "Close"
gadget and a limited function key capability. One nasty bug has been
fixed: no checking for "buffer full" was done in the prior version, so
if you typed more than 160 characters you got a visit from you-know-who.
Line Editing.
The DELETE and BACKSPACE keys function in the usual manner. The arrow keys
may be used for cursor positioning. The shifted left arrow moves the cursor
to the beginning of the line, and the shift right arrow moves to the end.
The default input mode inserts characters at the cursor; overstrike may
be toggled by CTRL-A. CTRL-X deletes the whole line, while CTRL-Y
deletes from the cursor position to the end of the line.
Tabs are replaced by blanks, so you can back up over them properly.
Command History.
Previously-entered lines may be recalled using the up-arrow. Lines are
retrieved sequentially; if you go past the one you want, the down-arrow
key will back up one. Shift up-arrow goes to the oldest line, and shift
down-arrow positions the pointer to the most recent line. The current
history buffer holds twenty input lines; this can be easily changed, once
I document the procedural calls to the ConHandler library.
Lines may also be recalled using the function keys (this will be the
default F-key action). Each key will recall the corresponding line
from the history buffer (excepted that I've temporarily usurped F1 & F2).
Window definition.
ConMan supports the usual DOS window specification string. For example,
"CON:160/50/320/100/MyWindow" specifies a window 320x100 pixels in size,
beginning in position (160,50). ConMan also accepts a specification in
the form "CON:w20480", where the hex digits following the "w" are the
absolute address of an Intuition window pointer. If you're writing in
'C', the following sequence would serve to open a window and attach a
DOS console to it:
window = OpenWindow(&newwindow); /* get a window */
sprintf(buffer,"CON:X%x",window); /* build the name string */
file = Open(buffer,MODE_OLDFILE); /* open a console stream */
The more arcane method of passing the window pointer to the handler
(as in Andy Finkel's Window example) should also work, but I haven't
tried it yet. (Let me know, if someone tries it).
Late-breaking news: at the suggestion of John Toebes, I've added the
ability to select which gadgets and attributes your window will have.
Here's how it works: Put another slash ('/') after the window title,
and follow it with any of the attribute options below:
A ==> activate (def: no activate)
B ==> BackDrop (def: not BackDrop)
C ==> Close gadget (def: no gadget) (action not implemented)
D ==> Depth gadget (def: depth gadget)
M ==> Move (drag) gadget (def: drag gadget)
N ==> NoBorder (def: border) (sorry, 'B' was used)
R ==> Refresh mode (def: SMART_REFRESH)
S ==> Sizing gadget (def: sizing gadget)
Z ==> Zero-Zero (def: not GZZ) (does anybody use this?)
Each attribute serves to TOGGLE the corresponding windows flag, so adding
it twice will cancel the effect. A closing slash is optional. For those
of you who wanted a slash in your titles: sorry.
Example: CON:10/10/300/100/Behind/nb/ creates a borderless backdrop window.
CON:10/10/300/100/Fixed/acm creates an active window, with a
close gadget, that won't budge.
One more addition: specifying CON:s123abc/10/10/300/100/ will attach
your window to the specified CUSTOMSCREEN. I only tried it on the
workbench screen, though (by digging the screen pointer out of
IntuitionBase). Let me know if it works on real custom screens.
Question: does anyone want to pass in a Super-Bitmap pointer? If so,
suggest a reasonable syntax that doesn't clash with the above ...
Installation.
ConMan requires that two files be copied to your SYS: disk (don't worry,
they're both small.) "My-Handler" (144 bytes) must be placed in
the SYS:L directory, to keep all those bigger handlers company. The
file "conhandler.library" (4328 bytes) must be placed in the your LIBS:
directory, which is normally SYS:LIBS. Once these files are present,
execute ConMan (852 bytes) to install the handler. This file only needs
to be run once (e.g. from your startup-sequence); it allocates 20 bytes
of memory for the handler name string which won't be returned (there are
no provisions in DOS for removing handlers, anyway.) The ARCed files
have shortened names, so be sure to rename "conlib.lib" and "myhandlr."
A simple "install" script is included to copy files.
Distribution.
This program is to be distributed as shareware to Amigoid life-forms
everywhere! Make sure your friends get a copy. Comments and contributions
will be appreciated and may be sent to:
William S. Hawes (bix: whawes)
P.O. Box 308
Maynard, MA 01754
(617) 568-8695
Further Notes.
This Beta version still has some debugging code in it. Function key F1
toggles a flag that causes a DisplayBeep everytime a WaitForChar packet
is dispatched. Most programs will not use the WaitForChar function,
since a Read to a CON: device will block until characters are available
anyway. F2 toggles a flag that DisplayBeeps whenever a "break" signal is
passed on (i.e. is applied to your hapless task). Also, an extraneous
message port (called 'MyCon) will appear in the Ports list. These testing
features will go away shortly.
The program was developed and tested under V1.2; at least one V1.1
dependency was found and fixed (DoIO to the console device scratched D7).
Let me know if other problems exist. I spent a lot of time making it
work using the DOS handler-loading mechanism so that it would be backwards
compatible.
ConMan does not pre-allocate a history buffer for the commands, but
rather allocates just enough for each string. This means that the
available memory changes after every command ... the memory isn't lost,
but it makes it difficult to tell if a program under development is
misbehaving. This will be changed in the next release.
Some of the things I'm thinking about adding include:
-- Support for the function keys and help keys. I'm designing a
general-purpose data structure to support context-sensitive
function and help key definitions. Keys should support both
string-substitution and event-type actions. Any ideas in these
directions?
-- The ConMan handler is built as a standard shared library. Various
entry points will be brought out and documented, and procedural
calls will be available to manipulate the internal data structures.
This will allow you to retrieve the window pointer by something
straightforward like "window = ConsoleWindow(filehandle);".
I may even write the binding routines for calls from 'C' ...
-- Most of the support for switchable CON:/RAW: operation is in place.
I still have to check on a few things (like, what was that new packet
type, anyway?)
-- How about adding a "dynamic piping" capability, so that an I/O
stream could be diverted on the fly into (or out of) a file? Ideas?
-- I plan to release the source code (in assembler) once things are
cleaned up a bit. It will be very helpful to anyone needing to
write a DOS handler. In the meantime, take a look at the included
"handler.asm" file: it provides a simple way around the problem
of writing BCPL look-alike programs.
-- Another tip: debugging handlers is easy if you try the following
trick. Run the handler program as a normal process under your
favorite debugger. Have it open a public message port, which can
located by a test driver running separately. The driver now
installs your processid ("pr_MsgPort, obtained by following the
MP_SIGTASK trail from your public port) in its "pr_ConsoleTask" slot,
and then does an Open('*',MODE_OLDFILE). Voila! Any I/O done by
the driver comes under the scrutiny of your debugger. You can
get things working before having to worry about installing the
handler in a device node. (An occasional message collision will
occur, since the debugger is probably doing I/O through the
processid message port. Not to worry ...)
-- Look for a super-whiz-bang display manager from the Software
Distillery in the near future. I've passed along the source code
to John Toebes et al; they've got plans for a window manager to
rival those found on the pricey workstations.
-- WSH (4/18/87)
=======================================================================
* DEFDISK
*
* A program to make a specified disk/directory the default system disk.
* It accomplishes this by resetting the DOS library structures to point
* to the new path. To use this program you will need to compile it as
* follows:
* 1> cc defdisk
* 1> ln defdisk.o -lc
*
* Real simple. I used AZTEC C v3.40a, but I think that 3.30c or later would
* also work. It should be possible to compile & build it under LATTICE as
* well, though I haven't tried. Once the program is built, put it on your
* Workbench boot disk somewhere, load up your ram: disk or hard disk and
*
* 1> defdisk dh0:
* or
* 1> defdisk dh0:bin
*
* Woila! the standard workbench assignments are now pointed at the hard
* disk. (SYS, C, L, DEVS, LIBS, FONTS) The advantage to me in using this
* is that I don't have to load the Amiga DOS assign program 6 times to
* point the system at the hard disk.
*
* Author: J. K. Levie
*
* Version 1.0 31-Mar-1987
*/
=======================================================================
/** SetPrefs
*
* SetPrefs, Copyright (C) 1987 by W.G.J. Langeveld
*
* Description:
* ------------
* Have you ever had the problem that you reassigned all your system
* directories to your hard disk or to another floppy or to your re-
* coverable ram disk, and at some point changed and saved your Pre-
* ferences, but to the wrong place? So that when you have to boot
* you wind up with the same old preferences that AmigaDOS picks up
* from the system-configuration file on the floppy you boot from?
* If so, this is a program for you. You run it in your startup-
* sequence AFTER you have reassigned especially devs: to your other
* device. This program will then read the system-configuration file
* in the new devs: directory and set your default preferences accor-
* dingly.
* Moreover, if you just want to use the preferences from some
* other disk or file, you can specify it on the command line: in
* that case the program will search for the specified file rather
* than 'devs:system-configuration'.
*
* Examples of use:
* ----------------
* (1) A sample startup-sequence might look like:
*
* assign C: hd0:c
* assign S: hd0:s
* assign L: hd0:l
* assign FONTS: hd0:fonts
* assign DEVS: hd0:devs
* assign LIBS: hd0:libs
* assign SYS: hd0:
*
* echo "Everything reassigned"
*
* SetPrefs
*
* (2) Suppose I would like to have the colors I get when booting from
* my DrofNats program disk, but don't want to boot from it. I could
* either get into Preferences and set the colors from memory, or I
* could type from the CLI:
*
* 1> SetPrefs DrofNats:devs/system-configuration
*
* If the DrofNats disk is not in a drive, AmigaDOS will prompt you
* to insert it.
*
* (3) Suppose I have a hard disk (I don't) but would like to change the
* set-up on occasion, because e.g. sometimes I use a different
* monitor than other times. One might have several system-configura-
* tion files stashed away someplace, and change to any one of them
* by typing from the CLI:
*
* 1> SetPrefs :configfiles/config25
*
* You can make config files by going into preferences, saving them
* and copying the resulting system-configuration file (Preferences
* always writes to devs:system-configuration):
*
* 1> copy devs:system-configuration :configfiles/config25
*
*
* Have fun!
* Willy.
*
***On this disk the examples are in Utilities/SP directory***
========================================================================
IconType
A useful utility for changing the type of an icon after editing with IconEd.
The "Kick" icon type is not supported, mainly because I can't see a use for
it. If you have a use, let me know, and I'll put it in. Typing the command name
by itself or with a "?" for an argument will print a short "usage" message.
Please note that if you change the type of an icon that is currently
displayed in a window, the window must be closed, then re-opened before you
will see any change in the "INFO" for that icon.
Usage is as follows:
IconType clock.info project (change "clock.info" to a "project" icon)
IconType tools.info drawer (change "tools.info" to a "drawer" icon )
Valid icon types are Disk, Drawer, Tool, Project, Garbage, and Device.
=====================================================================